![[Pivotal Tracker] スクラムのプロジェクトを管理するひとつの例](https://devio2023-media.developers.io/wp-content/uploads/2020/09/eyecatch_pivotal_tracker.png){kind=tracking}
[Pivotal Tracker] スクラムのプロジェクトを管理するひとつの例
Pivotal Trackerはアジャイル開発に特化したプロジェクト管理ツールです。 慣れるまで分かりにくかったりするため、具体的にどう使えば良いのか？の例として紹介していきます。 この通りにプロジェクト管理する必要はありませんが、少しでも参考になれば幸いです。
おすすめの方
- スクラムでの開発（アジャイル）の管理ツールを探している方
- Pivotal Trackerをざっくり知りたい方
- Pivotal Trackerを使い始めた方
最初にプロジェクトの設定をしよう
Pivotal Trackerでプロジェクトを作成した直後は、プロジェクト設定を見ることをおすすめします。
特に下記の項目をこれから始めるスクラムに合わせて調整しましょう。
- Start Iterations On
- Iteration Legnth
- Point Scale
- Initial Velocity
少し補足すると、Pivotal Trackerは、スプリントあたりのベロシティを自動計算してくれます。「このチームの過去nスプリントの様子を見ると、1スプリントあたりのベロシティはxxだよ」という具合です。1ポイントあたりの重みはチームで認識を合わせる必要がありますが、初期値としてInitial Velocityを設定できます。
ストーリーの種類を把握しよう
Pivotal Trackerでは、4種類のストーリーを作れます。
- Feature
- Chore
- Bug
- Release
Featureのストーリー
チームの顧客に対して価値を提供するストーリーです。Featureストーリーを作る場合は、次のようなタイトルを用いると、誰にとって何が嬉しいのかが分かりやすくなります。（優先順位の判断も行いやすい）
- xxxは、yyyがしたい。なぜならzzzだからだ。
具体的なタイトルの例は下記です。
- 買い物客は、商品一覧ページに1秒未満で遷移したい。なぜなら検索が遅いと購入する気が無くなるからだ。
- 警備員は、xxxの異常を電話で知りたい。なぜならすぐに駆けつけて解決したいからだ。
- など
……「なぜなら」以降を考えるのが地味に大変だったりします。検証したい価値や仮設ですね。どこまでも考えることができるので、なぜなぜを意味もなく深堀りしないように注意が必要です。適度に切り上げましょう。
Choreのストーリー
チームの顧客に対して価値を提供しないストーリーです。一言でいうと雑用ですね。
- SSL証明書を更新する
- CI/CDパイプラインを見直して改善する
- Lambdaで使っているPythonを3.6から3.8にしたい
- など
バグのストーリー
バグですね。
- xxx画面からyyy画面に遷移したい(404エラーになっている)
- 注文画面の表記を「税別」にしたい（今は「税込」表記）
- など
個人的にはタイトルの付け方（現状を書く or あるべき姿を書く or 両方書く）で地味に迷いますが、チームで話し合えればよいですね。
リリースのストーリー
リリースを扱います。「m月d日にバージョンx.y.zをリリースします」というマイルストーンを作成できます。
実際の使い方としては、プロダクトバックログの中で「ここより上側をバージョンx.y.zとしてm月d日にリリースします」という目印として機能します。 たとえば下記の状態だと、「警備員は、xxxの異常を電話で知りたい。なぜならすぐに駆けつけて解決したいからだ。」までをv1.2.3としてリリースすることを表しています。
このとき、もしも「管理者は、昨日のxxxの異常をメールで一覧で知りたい。なぜなら……」までをv1.2.3としてリリースする場合は下記となり、このままだと間に合わない事がすぐに分かります。
スプリントプランニングで計画を立てよう
チームが使える時間の割合を設定する
プロジェクトの設定でも書いたとおり、Pivotal Trackerはスプリントあたりのベロシティを自動計算してくれます。その値にチームが使える時間の割合を設定することで、「次のスプリントで消化できるポイントの見込み」が分かります。
チームが使える時間の最大値を100％とします。たとえば、開発チームが3人であれば、8時間×5日間×3人=120時間が100％とみなします。
とはいえ、毎日8時間きっちりストーリの進行に割り当てることは現実的に無理です。いろいろな時間が発生します（下記時間は目安）。
- プロジェクト関連で発生する時間（固定）
- スプリントプランニング：1時間×3人
- デイリースクラム：30分×5日×3人
- スプリントレビュー：1時間×3人
- スプリントレトロスペクティブ：1時間×3人
- リファインメント：30分×3人
- など
- プロジェクト関連以外で発生する時間（変動）
- 社内の打ち合わせ
- 社内の昼礼
- 社内の研修
- 休暇
- 遅めに出勤、早めに退勤
- など
このあたりは、1日を8時間ではなく6時間とみなしたり、チームで決めると良いです。
もろもろを合計して、「チームが使える時間の最大値（120時間）」から「チームが使えない時間（仮に32時間）」を引いた時間が「チームが実際に使える時間（88時間）」になります。このときチームが使える時間の割合は「73％」となり、この値を入力します。
上記の場合、次のスプリントで消化できるポイントが7となり、ゴールが自動的に可視化されます。
自分たちでスプリントゴールを設定する
BugやChore（0ポイントのストーリー）がたくさんあっても、合計0ポイントと換算されます。 そのため、「0ポイントのストーリーが多いけど、現実的には全部のゴールは無理……」なんてことが起こりえます。そのため、下記のように自分たちでゴールを設定すると分かりやすくなります。もちろん、プロダクトオーナーと合意をしましょう。
ストーリーのタスクを決める
各ストーリにはタスクを追加できます。開発チームは、このタスクを有効に使って作業すると良いです。観点としては、「受け入れ条件を満たしてFinishするためににやること」ですね。
ひとつのストーリーのライフサイクル(Feature・Bug・Chore)
ストーリの誕生から完了までの一連の流れを見ていきます。それぞれの工程で「誰がいつ何をするのか？」が分かります。
- 新しいストーリーをIceboxに作る
- チームで認識を合わせる
- 開発チームが見積もりする
- readyラベルを付ける
- プロダクトバックログに移す
- 着手する
- レビュー状態にする（Feature・Bug）
- レビューする
- レビューの判断をする
- Finish!!!（Chore）
2番〜5番はできるときに実施すればOKなので、順序が逆転してもOKです。
Pivotal Trackerにおけるストーリーの状態は下記が参考になります。
1. 新しいストーリーをIceboxに作る
- 作る人：だれでもOK
新しいストーリーは誰でも作成OKです。プロダクトオーナーでも良いし、開発チームでも良いし、スクラムマスターでも良いのです。
Add Storyを選択すれば作成できますが、テンプレートを作成すると便利です（後述）。
ひとまずタイトルとdescriptionを記入すればOKです。
2. チームで認識を合わせる
- 認識合わせする人：チーム全員
チーム全員で認識をあわせましょう。
- 目指す未来（ゴール）は何か？（タイトル）
- なぜこのストーリーが必要なのか？
- 現状はどうなっているのか？
- ゴールの具体的な条件は何か？（完了条件）
- など
忘れないようにするため、必要に応じてdescriptionに追記していきます。
3. 開発チームが見積もりする（Featureのみ）
Featureの場合
- 見積もりする人：開発チーム
見積もりはポイントで行います。1ポイントあたりの重さはチームで話し合えば良いですが、あくまでも参考として下記が挙げられます。
- フィボナッチ数の場合
- 1スプリント = 1週間の場合
| ポイント | 重さ |
|---|---|
| 0 | すぐ終わる |
| 1 | 1人で1日ぐらい |
| 2 | 1人で2-3日ぐらい |
| 3 | 1人で5日ぐらい（1スプリント全部使う） |
| 5 | 複数人で5日ぐらい（1スプリント全部使う） |
| 8 | めっちゃ掛かる。現実的じゃない。ストーリーの分割とかの見直しなどが必要 |
見積もった結果のポイントが大きい場合は、難しい判断が迫られます。
- さらに最小の価値は何か？を考えてストーリーを分割する
- それでもGOする（最小の価値に切り出せない、など）
- など
スクラムあるあるですが、「Aさんがやると2ポイントだけど、Bさんだと1ポイントなので、このストーリーは1ポイント」ではなく、チームとしてのポイントを見積もるようにしましょう。
BugとChoreの場合
BugとChoreの場合はポイント見積もりができません。これは、高いベロシティを目指すことが目的と化した場合、簡単にハックできるからです。
- Featureのストーリーでわざとバグを残しておく（ポイント:2）
- バグが発覚する
- Bugのストーリを作成する（ポイント:2）
- トータルのポイントが
4になった！！！（ハック成功
この設定を変更すればBugとChoreでポイント見積もりをすることはできますが、強く非推奨とされています。
4. readyラベルを付ける
- readyラベルを付ける人：誰でも
- readyラベルを付けるタイミング：認識合わせと見積もりの両方が終わっているとき
readyラベルは、「このストーリーはいつでも着手可能です！」を表します。
つまり、認識合わせと見積もりの両方が終わっている状態です。
そのため、プロダクトバックログの中で優先順位が変化してもなんの問題もありません。
デイリースクラムやリファインメントのとき、readyラベルが無いストーリを優先的に見ることができるため分かりやすくなります。
なお、ラベルは好きな文字列を付けられるので、チームで話し合ってラベル運用のルールを決めると良いですね。
5. プロダクトバックログに移す
- プロダクトバックログに移す人：プロダクトオーナー
IceBoxにあるストーリは、プロダクトオーナーが優先順位を決めつつプロダクトバックログに移します。
移すタイミングはreadyになってからが分かりやすいです。
6. 着手する
- 着手する人：開発チーム
実際にそのストーリーを開始したとき、Startを押せば着手状態になります。
Startすると色が変わってアサインされます。
7. レビュー状態にする（Feature・Bug）
- レビュー状態にする人：開発チーム
ストーリーの完了条件を満たしたら、Finishボタンを押してデリバリー中の状態にします。
この状態でレビュー準備を行い、「いつでもレビューできるぞ！！！」となったとき、Deliverを押してレビュー状態にします。
8. レビューする
実際にレビューを行いましょう。
9. レビューの判断をする
- レビューの判断をする人：プロダクトオーナー
プロダクトオーナーは、ストーリーのAcceptまたはRejectの判断を行ってボタンを押します。
Rejectのとき
Rejectを選択すると、状態が未着手に戻ります。
改めて対応開始するときはRestartを選択して進行中の状態にしましょう。
Acceptのとき
完了状態になります。お疲れさまでした！
10. Finish!!!（Chore）
Choreの場合は、レビュー状態が存在せず、そのままFinish状態になります。
Pivotal Trackerを上手く使うコツ
ストーリーのテンプレートを作る
ストーリーのテンプレートを用意しておき、新しいストーリーを作る際はテンプレートをコピーして作ると便利です。
もちろん、テンプレート内のDescriptionも記載できます。
不具合のテンプレートであれば、下記も含めると良いですね。
- 発生日時：yyyy/mm/dd hh:mm - hh:mm - 発生環境： - 発生事象： - 期待動作： - 影響範囲： - 発生バージョン： - 原因：
上記の場合、「新しいストーリーは、テンプレート用のストーリーをコピーして作成」しますが、下記のように公式機能を使うこともできます。
タスクも含めてテンプレート化したい等の理由があるなら、テンプレート用のストーリーを用意するほうが楽です。
Activityを活用する
ストーリー毎にActivityを書けるため、調査したメモを記入したり、検証用ファイルを添付したりなどで活用しましょう。
タイムボックスを表現する
「この時間しか使いません！」というタイムボックスを作る場合があります。
タイムボックスは運用でカバーします。具体的には、タイトルに[TB 1h*2]と含めると分かりやすいです。この場合は、「1時間を2人でやる」を表します。
spikeを表現する
「このストーリーを見積もりたいけど、不明点や検討事項が多すぎて見積もれない」ことってありますよね。
そんなときは事前調査用のストーリーとしてspikeを使います。（spike自体の出どころはエクストリームプログラミングです）
派生元のストーリーを複製して作ると楽です。
複製後はラベルにspikeを付与します。あとは他と同じですね。ただし、spikeの完了条件は、「本体のストーリーが見積もれること」です。
spikeを作りすぎると管理しにくい、かつ、価値あるものが届くのが先延ばしになってしまう（spikeで1スプリント、次のスプリントで実際の開発）ため、ほどほどにしておくと良いかもしれません。
スプリント内にストーリー（Feature）が終わらなかった場合は、終わった分だけDoneにする
スプリント内にゴールできないストーリー（Feature）が発生したとき、ストーリーを分割してスプリント内で消化したポイントを割り当てます。 たとえば、2ポイントのストーリがあるとします。
このストーリがスプリント内で50％完了したなら、1ポイントずつのストーリーに分割します。 分割することによって、スプリント内で消化したポイント（ベロシティ）を正確に導けるようになります。
ただし、単純に見にくくなったり情報分散することになるので、「長期的にベロシティは平均化される」「ベロシティを振り返る際に留意する」などスクラムマスターとも相談しつつ実施可否を検討すると良いです。
さいごに
実際にプロジェクトが始まると、「アレはどうなんだろう？」「コレはどうなんだろう？」と疑問に思うことがたくさん登場します。 疑問点が出てきたという事実がGoodであり、それぞれについて話し合って前に進んでいくことが大切ですね。
